home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
gem
/
l_0399
/
124
< prev
next >
Wrap
Internet Message Format
|
1994-08-27
|
2KB
Date: Tue, 31 May 1994 13:34:47 -0400 (EDT)
From: Timothy Miller <millert@undergrad.csee.usf.edu>
Subject: Re: Colour.
To: gem-list@world.std.com
In-Reply-To: <199405310906.LAA06920@blade.stack.urc.tue.nl>
Message-Id: <Pine.3.87.9405311347.A24625-0100000@undergrad>
Mime-Version: 1.0
Precedence: bulk
On Tue, 31 May 1994, Erlend Nagel wrote:
> I wrote:
>
> > > But a program could do a request for a colour within a certain margin
> > > from some value.
>
> Timothy wrote:
>
> > No. An app should be able to get EXACTLY what color it asks for.
>
> I probably was a bit unclear. The way I saw it, a program sends a
> request for colour X with margin 0 and then it should get EXACTLY that
> colour. Nice uh?
>
> Erlend.
>
Quite, but I think me may be deviating slightly. The manager is going to
have to manage many palettes, one for each window, and it may not matter
what's in the palette.
I suppose the manager might have facilities for helping the app to build
a palette that is as close as possible to the current one, but if an app
doesn't follow our standard, the manager's going to have to handle the
palette changes automatically anyway.
Some apps (like GEMview) change the palette when topping a window, but
this shouldn't conflict with our manager as long as the manager is able
to record the palette belonging to a GEMview window just before it's
untopped, so that when the window is topped, GEMview and the manager both
set the same palette.
The problem is catching the system JUST before a misbehaved app sets the
palette of its newly topped window so the palette for the untopped window
can be recorded. Is WM_UNTOPPED broadcast globally? Is it broadcast
BEFORE WM_TOPPED? If so, then there is no problem.